Why oh why are they so hard to write? Even using the built in modules it is insanely hard to debug. Playing a bootsplash in X sucks and my machine boots too fast to test it on reboot. Basically, euch. All I wanted was a hackers zebra on boot :(

Hello, World! For those of you who enforce my Sundays on me (keep doing that, thank you!), I ll be changing my Saturdays with my Sundays. That s right! In this new brave world, I ll be taking Saturdays off, not Sundays. Feel free to pester me all day on Sunday, now! This means, as a logical result, I will not be around tomorrow, Saturday. Much love.

More hardware adventures. I got my Dell XPS13. Amazing. The good news: This MacBook Air clone is clearly an Air competitor, and easily slightly better in nearly every regard except for the battery.
The bad news is that the Intel Wireless card needs non-free (I ll be replacing that shortly), and the touchpad s driver isn t totally implemented until Kernel 3.16. I m currently building a 3.14 kernel with the patch to send to the kind Debian kernel people. We ll see if that works. Ubuntu Trusty already has the patch, but it didn t get upstreamed. That kinda sucks. It also shipped with UEFI disabled, and was defaulting to boot in legacy mode. It shipped with Ubuntu, a bit disappointed to not see Ubuntu keys on the machine. Touchscreen works; in short -stunning. I think I found my new travel buddy. Debian unstable runs great, stable had some issues.

A few interesting things happened after I got a macbook air.

Firstly, I got a lot of shit from my peers and friends about it. This was funny to me, nothing really bothered me about it, but I can see this becoming really tiresome at events like hackathons or conferences.

As a byproduct, there s a strong feeling in the hardcore F/OSS world that Apple hardware is the incarnation of evil.

As a result of both of the above, hardcore F/OSS (and Distro hackers) don t buy apple hardware.

Therefore, GNU/Linux is complete garbage on Apple hardware. Apple s firmware bugs don t help, but we re BAD.

Some might ask why this is a big deal. The fact is, this is one of the most used platforms for Open Source development (note I used that term exactly).

Are we to damn these users to a nonfree OS because we want to maintain our purity?

I had to give back my Air, but I still have a Mac Mini that i ve been using for testing bugs on OSX in code I have. Very soon, my Mac Mini will be used to help fix the common bugs in the install process.

Some things you can do:

• Consider not giving off an attitude to people with Apple hardware. Be welcoming.
• Consider helping with supporting your favorate distro on Apple hardware. Props to Fedora for doing such a great job, in particular, mjg59 and Peter Jones for all they do with it.
• Help me make Debian Apple installs one-click.

One which ends in tears, I m afraid. A week or so ago, I got an MacBook Air 13 (MacBook Air 6-2), to take with me when I head out to local hack sessions, and when I travel out of state for short lengths of time. My current Thinkpad T520i is an amazing machine, and will remain my daily driver for a while to come. After getting it, I unboxed the machine, and put in a Debian install USB key. I wiped OSX (without even booting into it) and put Debian on the drive. To my dismay, it didn t boot up after install. Using the recovery mode of the disk, I chrooted in and attempted an upgrade (to ensure I had an up-to-date GRUB). I couldn t dist-upgrade, the terminal went white. After C-c ing the terminal, I saw something about systemd s sysvinit shim, so I manually did a purge of sysvinit and install of systemd. I hear this has been resolved now. Thanks :) My machine still wasn t booting, so I checked around. Turns out I needed to copy over the GRUB EFI blob to a different location to allow it to boot. After doing that, I could boot Debian whilst holding Alt. After booting, things went great! Until I shut my lid. After that point, my screen was either 0% bright (absolutely dark) or 100% (facemeltingly bright). I saw mba6x_bl, which claims to fix it, and has many happy users. If you re in a similar suggestion, I highly suggest looking at it. Unfortunately, this caused my machine to black out on boot and I couldn t see the screen at all anymore. A rescue disk later, and I was back. Annoyingly, the bootup noise s volume is stored in NVRAM, which gets written out by OSX when it shuts down. After consulting the inimitableMatthew Garrett, I was told the NVRAM can be hacked about with by mounting efivarfs on /sys/firmware/efi/efivars type efivarfs. Win! After hitting enter, I got a kernel panic and some notes about hardware assertions failing. That s when I returned my MacBook and got a Dell XPS 13.
This is a problem, folks. If I can t figure out how to make this work, how can we expect our users? Such a shame the most hardware on the planet gets no support, locking it s users into even less freedom.

This week, I started work on something I m calling moxie. Due to wanting to use my aiodocker bindings on the backend, I decided to implement it in 100% AsyncIO Python 3.4. What pushed me over the edge was finding the aiopg driver (postgres asyncio bindings), with very (let me stress - very) immature SQLAlchemy support.

Unfortunately, no web frameworks support asyncio as a first-class member of the framework, so I was forced into writing a microframework. The resulting app looks pretty not bad, and likely easy to switch if Flask ever gets support for asyncio. One neat side-effect was that the framework can support stuff like websockets as a first-class element of the framework, just like GET requests. Moxie will be a tool to run periodic long-running jobs in a sane way using docker.io. More soon!

I ve been learning about android development over the last few weeks, and I think I m slowly getting the hang of best practices. It s a bit tough, there s a lot of stuff that s not super Java-idomatic that s become Android-idiomatic, so getting over that stuff has been interesting. I ve been finding that Android tends to re-implement most things in a similar enough way, but always with some small tweak that feels kinda funny. It s working well enough, and I m hoping that I can clean up a few android libraries to deal with some of the OpenGov datasets I m interested in. If anyone has any tips on proper handling of what to make a fragment, and what activities should look like, I d really love posts about that. It seems like sometimes I have a 1-to-1 mapping of Fragments to Activity, but I want to keep it a fragment for large devices. Anyway, best practices welcome.

Great time, super well organized by this year s TCamp staff. Really outstanding. Lots of really amazing discussion, and I feel a lot of effort is finally jelling around Open Civic Data, which is an absolute thrill for me. Can t wait to see what the next few months bring!

I've been using Linode since 2010, and many of my friends have heard me talk about how big a fan I am of linode. I've used Debian unstable on all my Linodes, since I often use them as a remote shell for general purpose Debian development. I've found my linodes to be indispensable, and I really love Linode. The Problem Recently, because of my work on Docker, I was forced to stop using the Linode kernel in favor of the stock Debian kernel, since the stock Linode kernel has no aufs support, and the default LVM-based devicemapper backend can be quite a pain. I tried loading in btrfs support, and using that to host the Docker instance backed with btrfs, but it was throwing errors as well. Stuck with unstable backends, I wanted to use the aufs backend, which, dispite problems in aufs internally, is quite stable with Docker (and in general). I started to run through the Linode Library's guide on PV-Grub, but that resulted in a cryptic error with xen not understanding the compression of the kernel. I checked for recent changes to the compresson, and lo, the Debian kernel has been switched to use xz compression in sid. Awesome news, really. XZ compression is awesome, and I've been super impressed with how universally we've adopted it in Debian. Keep it up! However, it appears only a newer pv-grub than the Linode hosts have installed will fix this. After contacting the (ever friendly) Linode support, they were unable to give me a timeline on adding xz support, which would entail upgrading pv-grub. It was quite disapointing news, to be honest. Workarounds were suggested, but I'm not quite happy with them as proper solutions. After asking in #debian-kernel, waldi was able to give me a few pointers, and the following is very inspired by him, the only thing that changed much was config tweaking, which was easy enough. Thanks, Bastian! The Constraints I wanted to maintain a 100% stock configuration from the kernel up. When I upgraded my kernel, I wanted to just work. I didn't want to unpack and repack the kernel, and I didn't want to install software outside main on my system. It had to be 100% Debian and unmodified. The Solution Left unable to run my own kernel directly in the Linode interface, the tact here was to use Linode's old pv-grub to chain-load grub-xen, which loaded a modern kernel. Turns out this works great. Let's start by creating a config for Linode's pv-grub to read and use. Now, since pv-grub is legacy grub, we can write out the following config to chain-load in grub-xen (which is just Grub 2.0, as far as I can tell) to /boot/grub/menu.lst. And to think, I almost forgot all about menu.lst. Almost. Just like riding a bike! Now, let's install and set up grub-xen to work for us. And, let's set the config for the GRUB image we'll create in the next step in the /boot/load.cf file: Now, lastly, let's generate the /boot/xen-shim file that we need to boot to: Next, change your boot configuration to use pv-grub, and give the machine a kick. Should work great! If you run into issues, use the lish shell to debug it, and let me know what else I should include in this post! Hack on!

Hello, World! I ve deployed my first instance of lenin to my backup VCS (lucifer.pault.ag), and it s going great. (Screenshot of the first few instances for good measure) I m excited to see how it develops!

Ohanayou? Ohanami!

I gave a talk this year at PyCon 2014, about one of my favorite subjects: Hy. Many of my regular readers will have no doubt explored Hy's thriving GitHub org, played with try-hy, or even installed it locally by pip installing it. I was lucky enough to be able to attend PyCon on behalf of Sunlight, with a solid contingint of my colleagues. We put together a writeup on the Sunlight blog if anyone was interested in our favorite talks. Tons of really amazing questions, and such an amazingly warm reception from so many of my peers throughout this year's PyCon. Thank you so much to everyone that attended the talk. As always, you should Fork Hy on GitHub, follow @hylang on the twitters, and send in any bugs you find! Hopefully I'll be able to put my talk up in blog-post form soon, but until then feel free to look over the slides or just watch the talk. An extra shout-out to @akaptur for hacking on Hy during the sprints, and giving the exception system quite the workthrough. Thanks, Allison!

As some of you know, I ve started to take Sundays off, and this is mostly a post to continue to hold myself accountable, and to assure everyone that yes! That s still going on! I ve found my Saturdays to be more productive, and my Sundays to be much more enjoyable and stress-free. For those that don t know, I m not even using any computer through my Sundays (hilariously dubbed paul-tag by my friends (only Germans would find this funny, though :) )), but my tablet and phone seem to be OK (but I actively avoid email) If anyone s on the fence, I highly recommend doing this, it s really great.

It sucks. It annoys me to no end that I can t run my own Linux kernel on an Android device. It s very annoying that the android patches haven t been upstreamed, and it s even more annoying that I can t run a host OS that I build lovingly and work on during the nights. I hate that I can t use my tablet as a porter box with a USB OTG Hard disk. Alas. One day. One day I ll have a proper armhf device that I can run Debian on. But that day is not today.

As of Pygments 1.7, there s support for Hy! http://pygments.org/docs/lexers/ Please report any bugs you find! This is great!

If you re the sort that cares about federation, the MediaGoblin project is for you!

MediaGoblin is a media hosting platform, where you can post all sorts of things, like video, images or even 3d models. It s a nice replacement for things like Flickr, and YouTube, and super easy to set up.

If I wasn t such a lazy person, I d have uploaded it to Debian, but alas. Soon. Soon!

It s an official GNU project, and it s maintainer, Chris is a totally awesome guy, and MediaGoblin is really important work.



If you feel the urge to support federation on the web, Support MediaGoblin! Help us take back the net!

I ve slowly come to the conclusion that I should likely not work as much as I do. Looking back over my GitHub graphs, and feeling my own internal pressure to do more work is getting to the point of insanity. I can t remember the last time I took a whole day off. As a result, I m going to make a new rule for myself, and put it in a semi-public place to help with peer-pressure enforcing this. I m not going to use my computer (except in vary rare and urgent circumstances) on Sundays, from here on out. The exact rules are still up in the air (Is the Phone OK? Tablet?) Let s see how this goes! I ll start next week (or just stop doing things today)

I ve spent a bit of time this saturday Dockerizing Debile s slave / workers (for those who don t know about Debile yet, there are a few posts where I explain it) Many thanks to Tianon Gravi for his work in helping me out :) I created two images to test - the base image for any slave (paultag/debile-slave-base, and a preconfigured image for our test master server. This includes a script to preconfigure the slave worker (OpenPGP keys, username, password) that are passed to it via a tarball generated by debile-remote. Hopefully this makes deploying debile slaves easier :) I was able to do a test build of about 300 packages with the dockerized slave, and I think it s a huge step forward. Onward!

I ve been hacking (on and off) on a small bit of code (written in Hy) called Acid. So, all of this is *really* fluid, and I m going to change it s API and code (it s currently just one massive hack), but I think the idea has kinda jelled enough for me to chat a bit about. Acid is a DSL for writing event-driven Hy. Currently it s just using global events (that ll change soon), and it s a monumental hack (not sure how much I can do there), but it works pretty well. It s built on top of tulip / asyncio, which is an amazing new Python 3.4 standard library package for working with async code. Although asyncio is designed around network-based usecases, I ve been trying to shoehorn in an event system on top of it. It s going well so far. A basic Acid script looks something like:

(trip
  (on :startup
    (every 1 second (emit :clock-pulse nil)))
  (on :clock-pulse (print "."))
  (emit :startup nil))

which will print a dot ( . ) every second forever. Something a bit more advanced (fetch the MBTA Red line T information once a minute forever)

(defn get-endpoint-url [line]
  (.format "http://developer.mbta.com/lib/rthr/ 0 .json"
    (get  :red-line  "red"
          :blue-line "blue"  line)))
(trip
  ;; OK. Let's do some work with MBTA feeds.
  (on :update-feed
      ;; let's just update feeds on a cron.
      (print (.json (.get requests (get-endpoint-url event))))
      (emit :feed-updated event))
  (every 1 minute
         (emit :update-feed :red-line)))

Clearly, both of these examples are just as clear as their straight functional counterparts, but I m keen to see what I can do with temporal recursion for long-running daemons. I think my first job will be porting snitch's codebase to Acid. Let me know if you have any ideas!